上一章節把後端骨架搭完了——Lambda 放程式碼、API Gateway 接入口、IAM 給權限、CloudWatch 能追蹤問題。從這篇開始進入 P要讓這個骨架真正「聰明」起來的環節了，第一件要解決的事，就是當使用者打進來的不是乾淨的表單欄位，是一句話的時候，怎麼辦?

基本資料表單（年齡、體重、活動量⋯⋯）都是結構化欄位，程式處理起來很單純。但自由文字欄位不一樣，使用者可能打「早餐都超商、常常十一點吃消夜」，也可能打「我不太喜歡吃海鮮，晚餐幾乎都外食」，同一件事，有無限種講法。

🧱 地基概念

傳統寫死規則的程式，碰到「一句話」會直接卡住

寫程式的直覺是把邏輯講清楚、寫死規則：如果 A 就做 X，如果 B 就做 Y。這招在結構化資料上很好用——年齡是數字、活動量是選單，程式一眼就能判斷。但碰到「使用者打的一句話」，規則會直接爆炸：光是「常吃消夜」這件事，使用者可能寫成一百種不同的句子，不可能寫一百條 if-else 去接住每一種講法，關鍵字比對也一樣，容易漏、容易誤判，換個講法就失效。

Generative AI 解決的是「理解語意」，不是「查表」

生成式 AI（Generative AI）背後是一種叫 LLM（Large Language Model，大型語言模型）的模型，被大量文字訓練過，核心能力不是查表，而是理解語意——「常常十一點吃消夜」跟「宵夜都吃很晚」，對它來說是同一件事，不需要窮舉所有講法。這個專案選用的是 Amazon Bedrock 上的 Claude 模型（Bedrock 是什麼，後面會細講）。

🔧 實際操作

這個專案怎麼用

Day8 提到的那個自由文字欄位（飲食習慣自述）送出後，後端不會自己動手解析，而是把整段文字連同一組明確的輸出格式要求，一起送進 Amazon Bedrock 呼叫 AI，請它把這段話轉換成程式碼看得懂的 JSON格式。這裡用的不是要 AI「生成新內容」，而是利用它「理解語意、抽取結構」的能力。

但這個彈性是有代價的

這系列文章接下來要不斷強調的一件事是：生成式模型的彈性也可能導致，同一個問題問兩次，答案可能不完全一樣，這就是幻讀(hallucination)的根源，後面也會分享。所以這個專案的設計，從一開始就是「讓 AI 做它真正擅長的事（理解語意），不擅長的事（精確計算）一律交給程式碼」。

小結

這篇先回答「為什麼要用生成式 AI」，但「AI 具體負責什麼、不負責什麼」這條界線要畫在哪裡，才是接下來真正的重點。